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ABSTRACT 


This  is  the  final  report  of  the  COMNAVMETOCCOM  Independent  Model  Review  Panel 
(CIMREP)  for  the  Voice  of  America  Coverage  Analysis  Program  (VOACAP),  version 
05.01 19W,  as  modified  by  the  Space  and  Naval  Warfare  Systems  Center  Pacific  (SSC- 
Pacific),  Atmospheric  Propagation  Branch  (5528).  VOACAP  is  a  tool  for  predicting  the 
perfonnance  of  High  Frequency  (HF)  radio  communication  systems.  The  authors 
evaluated  VOACAP  for  possible  inclusion  in  the  Oceanography  and  Atmospheric  Master 
Library  (OAML)  by  (1)  using  provided  and  online  documentation  from  HF  experts,  (2) 
installing  the  program  on  PCs,  (3)  running  a  series  of  test  cases  and  (4)  comparing  the 
output  results  with  other  HF  models  and  VOACAP  versions. 

The  core  physics  and  statistics  in  VOACAP  are  sound  and  this  product  could  potentially 
be  very  useful  to  the  US  Navy.  However  several  problems  were  identified  related  to  (1) 
difficult  installation  of  the  program,  (2)  limitations  on  usable  operating  systems,  (3)  lack 
of  ability  to  produce  important  output  variables  other  than  field  strength,  (4)  inadequate 
documentation,  and  (5)  the  need  for  training  and  support  for  the  successful  use  of  the 
program  or  products  derived  from  it.  For  these  reasons,  the  authors  cannot  recommend 
inclusion  of  the  submitted  version  of  VOACAP  in  OAML.  To  make  this  possible,  the 
Navy  would  need  to  provide  more  resources  for  the  development  of  a  suitable  product, 
and  support  for  the  product  once  it  has  been  included  in  OAML.  These  costs  need  to  be 
weighed  against  the  benefits  of  having  an  HF  prediction  product  included  in  tactical 
decision  aids  such  the  Naval  Integrated  Tactical  Environment  Subsystem  Next 
Generation  (NITES-NEXT). 
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I.  Introduction 

This  is  the  final  report  of  the  COMNAVMETOCCOM  Independent  Model 
Review  Panel  (CIMREP)  for  the  Voice  of  America  Coverage  Analysis  Program 
(VOACAP),  version  05.01 19W,  as  modified  by  the  Space  and  Naval  Warfare  Systems 
Center  Pacific  (SSC-Pacific),  Atmospheric  Propagation  Branch  (APB)  (5528).  This 
report  contains  a  technical  evaluation  of  the  VOACAP  model  and  accompanying 
documentation,  with  recommendations  concerning  inclusion  in  the  Oceanographic  and 
Atmospheric  Master  Library  (OAML).  VOACAP  is  a  prediction  tool  for  evaluating  the 
performance  of  High  Frequency  (HF)  radio  systems. 

VOACAP  has  a  long  history  and  has  been  validated  and  verified  (V+V)  by  a 
variety  of  past  studies  including  a  quality  assurance  verification  (QAV)  performed  by 
Lockheed  Martin  (20 10a, b)  and  documentation  provided  OAML-SDD-96  (2010a,b,c,d). 
The  authors  of  this  current  report  are  not  specifically  research  HF  experts,  but  P.  Guest 
has  extensive  background  knowledge  of  HF  transmission  issues  and  has  taught  a  course 
covering  this  topic,  designed  instructional  labs  and  online  educational  material  regarding 
HF  propagation  since  1993.  The  authors  are  members  of  the  Environmental  Effects 
Group  at  the  Naval  Postgraduate  School  (NPS)  in  Monterey  CA  and  have  considerable 
experience  developing  and  evaluating  Navy  environmental  prediction  products  and 
tactical  decision  aids,  writing  computer  code  in  PC  and  UNIX/LINUX  environments  and 
analyzing  environmental  effects  on  radio  frequency  (RF)  propagation.  The  authors 
determined  that  because  of  the  considerable  previous  V+V  efforts  performed  for 
VOACAP,  it  was  not  necessary,  nor  fiscally  justifiable,  to  convene  a  special  committee 
of  experts  to  perform  this  CIMREP.  Instead  the  authors  consulted  with  online  and  other 
sources  to  produce  this  report,  in  addition  to  performing  several  analyses  of  their  own. 

The  outline  of  this  report  generally  follows  the  recommended  format  with  some 
modifications.  After  this  introduction,  this  report  presents  some  background  infonnation 
on  HF  propagation  and  VOACAP,  followed  by  the  approach  taken,  the  findings  of  the 
study,  the  changes  required,  feedback  from  the  developer,  and  final  conclusions  and 
recommendation  for  inclusion  in  OAML. 

II.  Background 

A.  HF  Propagation 

1 .  HF  Primer 

This  section  presents  some  essential  background  infonnation  for  readers  who  may 
not  be  familiar  with  HF  communications.  HF  (sometimes  refened  to  as  “short-wave”) 
communications  were  the  primary  fonn  of  long  range  communications  before  the  satellite 
era.  Although  HF  refers  to  “High  Frequency”,  the  2  MHz  -  30  MHz  frequency  range 
represented  by  HF  is  lower  (and  has  longer  wavelengths)  than  most  forms  of 
communication  today.  HF  signals  can  propagate  in  a  variety  of  modes,  including  sky 
wave,  space  wave,  surface  wave  and  surface-reflected  wave  (the  latter  three  often 
referred  to  collectively  as  “ground  waves”).  Space  waves  are  direct  line  of  sight  (as 
modified  by  refraction)  paths;  for  HF  these  are  usually  cancelled  out  by  the  surface- 
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reflected  wave  and  therefore  neither  can  be  used  for  HF  communication.  The  surface 
wave  is  created  by  differences  in  the  dielectric  and  permitivity  characteristics  of  the  air 
and  ground  which  creates  a  “channel”  for  guiding  the  waves.  Surface  waves  are  an 
important  aspect  of  HF  communications  and  allow  RF  energy  to  travel  over  the  horizon 
for  medium  distance  (~0  -  500  km)  communications  (or  radar).  Commercial  AM  radio 
(in  the  MF  band)  is  an  example  of  a  communication  system  that  relies  on  surface  waves. 

A  unique  aspect  of  HF  radiation  is  the  ability  to  propagate  in  the  fonn  of  sky 
waves.  Sky  waves  refract,  i.e.  bend  downward  (hereafter  called  a  “reflection”)  in  the 
ionosphere  due  to  the  presence  of  charged  particles,  primarily  free  electrons.  The 
reflection  occurs  in  the  F  (during  the  day  subdivided  into  FI  and  F2)  layer  in  the 
atmosphere  which  exists  in  the  region  150-800  km  above  the  surface.  During  daylight 
hours,  reflections  can  sometimes  occur  in  the  E  layer  which  is  just  below  the  F  layer,  90  - 
150  km  above  the  surface.  The  D-layer,  60  -  90  km  above  the  surface,  absorbs  HF 
energy  in  the  daytime  and  limits  propagation  ranges.  Above  a  critical  frequency,  which 
depends  on  the  free  electron  density,  radio  waves  are  no  longer  reflected  and  proceed  into 
space,  making  skywaves  transmission  impossible.  The  frequency  at  which  this  occurs  for 
a  particular  propagation  angle  is  called  the  Maximum  Usable  Frequency  or  MUF. 
Another  parameter  often  used  is  the  Frequency  of  Optimum  Transmission  or  FOT, 
defined  as  the  MUF  times  0.85.  At  lower  frequencies,  the  radiation  is  absorbed  in  the  D 
layer,  depending  on  the  frequency  and  the  power  of  the  transmitter  (more  power,  greater 
ability  to  overcome  the  absorption).  This  lower  limit  is  called  the  Lowest  Usable 
Frequency  or  LUF.  At  night,  D  layer  absorption  is  neglible  and  the  LUF  is  usually  set  to 
an  arbitrary  value,  such  as  2  MHz.  Between  the  LUF  and  the  MUF,  the  radio  waves  will 
propagate  through  the  D  layer  and  reflect  from  somewhere  within  the  F  layer,  thus 
allowing  long  range  communications.  Figure  1  shows  some  of  these  concepts. 


Range  (km) 


Figure  1  Ray  trace  diagram  showing  sky  waves  at  different  frequencies.  The 
blue  ray  frequency  is  greater  than  the  MUF  and  passes  into  space.  The  green 
ray  frequency  is  less  than  the  MUF  but  greater  than  the  E  layer  MUF.  This  is 
usually  the  best  frequency  region  to  use  for  long  range  communications  and  is 
usually  where  the  FOT  (equal  to  0.85  x  MUF)  exists.  The  orange  ray  frequency 
is  less  than  the  E  layer  MUF  and  greater  than  the  LUF.  This  is  best  for  mid¬ 
range  (around  500  to  1500  km)  transmissions.  The  red  ray  is  a  lower  frequency 
than  the  LUF  and  is  absorbed  in  the  D  layer. 
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A  powerful  enough  signal  can  reflect  or  “bounce”  off  the  surface  and  again 
propagate  into  the  ionosphere,  to  be  reflected  downward  again.  A  typical  F  layer  bounce 
occurs  about  2000  km  from  the  transmitter;  multiple  bounces  can  propagate  all  around 
the  world  if  conditions  are  right.  Between  the  bounce  regions,  (especially  before  the  first 
bounce)  are  “skip  zones”  where  HF  communications  fail.  It  is  the  ability  to  reflect  off  the 
ionosphere  and  propagate  for  long  distances  that  makes  HF  communications  such  a 
powerful  tool. 

Complicating  the  issue,  events  originating  from  the  sun  (called  “space  weather”) 
can  affect  the  ionospheric  electron  density  and  therefore  the  value  of  the  MUF  and  LUF. 
Some  space  weather  events  follow  a  more  or  less  regular  1 1  year  cycle  (as  indicated  by 
sunspots)  while  others,  such  as  geomagnetic  storms,  are  less  predictable.  Sometimes 
conditions  produce  a  condition  where  the  MUF  is  lower  than  the  LUF.  During  these 
situations,  called  “short  wave  fadeouts”,  HF  skywave  communications  are  not  possible. 
Another  complication  is  interference  by  human  sources;  this  is  a  big  problem  in  urban 
areas  where  there  are  many  sources  (mostly  unintentional)  of  HF  radiation  “noise”. 

The  trick  to  performing  successful  HF  communications  is  to  choose  a  frequency 
higher  than  the  LUF  and  lower  than  the  MUF  and  to  insure  that  the  receiver  is  not  in  a 
skip  zone.  Unfortunately,  the  values  of  the  MUF  and  LUF  vary  greatly  in  every  24  hour 
period,  going  up  during  the  day  and  down  at  night.  So  it  is  not  possible  to  pick  a 
frequency  that  will  work  at  all  times  of  the  day  for  a  particular  transmitter/receiver  pair. 
This  is  where  a  model  such  as  VOACAP  comes  into  play.  Such  models  predict  the  signal 
strengths  and  probability  of  successful  communication  based  on  the  above  discussion  and 
other  factors  for  a  particular  frequency.  These  models  also  predict  the  values  of  the  LUF 
and  MUF  over  a  24  hour  cycle,  so  that  HF  operators  can  decide  beforehand  which 
frequencies  (if  any)  are  availble  for  use  at  for  a  particular  time  of  day. 

2.  The  Military  and  Civilian  uses  of  HF 

Before  about  1965,  HF  was  the  primary  form  of  long  range  communications,  at 
least  in  areas  not  serviced  by  direct  wire  commications.  With  the  advent  of  satellite 
communications  (which  use  frequencies  high  enough  to  penetrate  the  ionosphere)  the  use 
of  HF  by  the  US  Navy  was  drastically  reduced.  The  US  Anny  and  Air  Force  continued 
to  use  HF,  along  with  ham  radio  operators,  but  not  to  the  extent  as  in  previous  years.  The 
military  use  of  HF  is  still  very  important  in  some  allied  countries,  Australia  being  a 
notable  example.  There  is  also  a  concern  in  the  US  Navy  that  an  adversary  could  destroy 
our  communications  satellites,  which  would  make  long  range  communication  with  our 
ships  impossible,  which  would  be  a  tactical  and  strategic  disaster.  For  these  reasons, 
there  has  been  renewed  interest  within  the  US  Navy  to  maintain  a  capability  for  HF 
communications.  Due  to  the  idiosyncrasies  discussed  in  the  previous  sub-section,  ,the 
use  of  HF  also  requires  a  reliable  prediction  capability;  thus  the  need  for  including  a  HF 
prediction  model  in  the  OAML  library. 

B.  VOACAP 

1.  Brief  History 
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The  Voice  of  America  Coverage  Analysis  Program  (VOACAP)  traces  its  history 
back  to  the  1920’s  and  30’s  when  HF  communications  first  became  an  important  method 
for  long  distance  communications.  During  this  period,  the  importance  of  ionospheric 
conditions  became  apparent  and  manual  prediction  techniques  were  developed.  While 
successful,  these  techniques  were  laborious  and  time  consuming.  With  the  advent  of 
computers,  several  automated  prediction  programs  were  developed,  the  first  being  ITSA- 
1  in  1966.  By  1978,  ITSA  had  evolved  into  the  Ionosphere  Communication  Analysis  and 
Prediction  Program  (IONCAP),  developed  by  George  Haydon,  John  Lloyd  and  Donald 
Lucas  at  the  National  Telecommunications  and  Information  Administration,  Institute  for 
Telecommunications  Services  (NTIA/ITS),  US  Department  of  Commerce  with  funding 
and  input  from  the  US  Army  and  other  organizations.  In  the  mid  1980’s  NTIA  ceased 
work  on  IONCAP,  but  George  Lane  from  Voice  of  America  and  Frank  Rhoads  from  the 
Naval  Research  Laborator  (NRL)  in  Washingtion  DC  were  funded  by  the  Voice  of 
America  (VO A)  to  continue  development  of  an  HF  prediction  program.  The  improved 
program  developed  by  Lane  and  Rhoads  officially  became  VOACAP  in  1993  and  has 
been  used  by  VOA  ever  since.  The  core  model  has  remained  essentially  unchanged  from 
the  1993  version,  although  Greg  Hand  has  implemented  several  improvements  to  the 
software  package  and  environmental  inputs,  and  currently  maintains  a  web  site 
documenting  these  changes  and  other  information  about  VOACAP  at  http :  //w  w  w .  gre  g- 
hand.com/hfhtml.  Note  that  Hand  is  retired  from  NTIS/ITS  and  provides  support  on  a 
volunteer  basis;  he  is  the  only  person  currently  maintaining  VOACAP.  The  historical 
information  presented  here  is  from  OAML-SDD-96  (2010c),  the  “Luxerion”  web  site  at 
http://www.astrosurf.com/luxorion/qsl-soft-voacap.htm  and  links  in  the  “VOACAP 
Quick  Guide”  by  Jari  Perkiomaki  (http://www.voacap.com  ).  The  reader  is  referred  to 
these  documents  and  web  sites  for  details  on  VOACAP  history.  The  main  point  is  that 
VOACAP  represents  the  culmination  of  many  years  of  research  and  development  and, 
despite  not  undergoing  major  changes  in  the  physical  and  statistical  representations  for 
the  last  20  years,  it  is  still  considered  by  many  HF  experts  to  be  the  “gold  standard”  for 
HF  propagation  programs. 

2.  Description 

VOACAP  is  a  probabilistic  model  that  predicts  HF  propagation  between  a  radio 
transmitter  (Tx)  and  receiver  (Rx)  at  any  two  points  on  Earth  over  a  24  hour  cycle.  It 
also  predicts  global  areal  coverage  for  a  single  Tx  location  and  time.  VOACAP  predicts 
22  parameters,  including  Signal-to-noise  Ratio  (SNR),  Reliability  (%  chance  of 
successful  comms),  Required  Power  Gain,  Signal  Power,  Field  Strength  at  Receiver, 
MUF,  LUF  and  Propagation  Angle.  The  VOACAP  model  is  based  on  monthly  averages 
of  ionospheric  conditions,  Tx  and  Rx  system  characteristics,  antenna  and  surrounding 
ground  characteristics  and  man-made  noise. 

The  ionospheric  conditions  are  based  on  statistics  from  a  huge  number  (from 
more  than  35,000  locations)  of  observations  compiled  by  the  Comite  Consultatif 
International  des  Radio  Communications  (CCIR),  the  International  Union  of  Radio 
Science  (URSI)  and  other  sources,  using  inputs  of  sunspot  number,  10  cm  solar  flux  and 
the  3  hour  planetary  K-index,  the  latter  being  a  measure  of  magnetic  field  fluctuations 
associated  with  solar  activity.  The  program  takes  into  account  the  diurnal  and  solar 
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activity  cycles.  However,  because  VOACAP  is  primarily  a  statistical,  empirically-based 
model,  it  does  not  attempt  to  predict  solar  weather  events  associated  with  coronal  mass 
ejections  (CME)  and  other  space  weather  phenomena.  The  model  does  allow  the  input  of 
a  “multiplier”  for  free  electron  densities  in  the  E,  FI,  F2  layers,  which  a  knowledgeable 
user  could  use  to  account  for  space  weather  effects. 

The  Tx  and  Rx  system  characteristics  used  by  VOACAP  are  quantified  by  several 
system  parameters  (see  Appendix  A  for  specifics).  The  original  VOACAP  (available 
from  NTIA/ITS)  contains  a  data  base  of  hundreds  of  transmitter  and  receiver  systems  and 
a  large  number  of  antenna  types.  The  original  VOACAP  also  contains  a  detailed  data  set 
of  atmospheric  and  man-made  radio  noise,  as  developed  by  A.  D.  Spalding.  This 
estimate  of  radio  noise  is  available  for  locations  around  the  globe. 

The  information  for  this  section  is  based  on  the  informative  “Quick  Guide”  web 
site  developed  and  kept  up-to-date  by  Perkiomaki  (http://www.voacap.com).  In  addition 
to  detailed  descriptions  of  VOACAP  and  considerable  other  related  information,  this  site 
allows  the  user  to  run  the  model  online  and  produce  color-contoured  outputs  of  global 
areal  coverage  and  24  hour  point-to-point  predictions  for  a  particular  chosen  path 
showing  probability  of  communication  for  all  HF  frequencies.  From  the  latter,  the 
diurnal  cycle  of  the  MUF  and  LUF  can  be  easily  determined.  Much  of  the  information 
on  the  Perkiomaki  web  site  was  obtained  from  the  book  “Signal-to-noise  Predictions 
Using  VOACAP  -  A  User’s  Guide”  by  George  Lane  developed  under  contract  from 
Rockwell  Collins  (Lane,  2001).  Lane’s  guide  can  be  orderd  in  CD  version  from  the  site 
http://www.greg-hand.com/pc  hf/rockwell/. 

3.  VOACAP  Implementation  by  SSC-Pacific 

This  CIMREP  report  is  an  evaluation  of  the  VOACAP  version  that  was 
implemented  by  the  Atmospheric  Propagation  Branch  (APB)  5528  of  SSC-Pacific.  The 
information  in  this  section  is  based  on  four  documents  (VOACAP  Software  Test 
Description,  Software  Design  Document,  Software  Requirements  Specification  and 
Software  Modification  Document)  produced  by  the  APB  (OAML-SDD-96,  2010a,b,c,d) 
and  a  Quality  Assurance  Verification  (QAV)  Brief  Summary,  and  Full  Report  by 
Lockheed  Martin  (20 10a, b). 

SSC-Pac  ABP  obtained  VOACAP  version  05.01 19W  from  NTIA/ITS  in  2009. 
APB  SSC-Pac  did  not  make  any  changes  to  the  physical  and  statistical  algorithms  within 
the  VOACAP  model  nor  did  they  change  any  of  the  input  parameter  requirements. 
However,  APM  SSC-Pac  made  several  modifications  to  the  FORTRAN  source  code  to 
meet  Navy  requirements  for  inclusion  in  the  Naval  Integrated  Tactical  Environment 
Subsystem  Next  Generation  (NITES-NEXT)  which  is  the  tactical  decision  aid  program  of 
record  (POR)  of  the  Navy  Program  Executive  Office  (PEO  C41).  This  effort  was  part  of 
SSC-Pac  plan  to  develop  the  Radio  Frequency  Propagation  Service  (RFPS)  which  is  a 
service-oriented  approach  (SOA)  for  providing  electromagnetic  (EM)  propagation 
models  used  by  NITES-NEXT  developers. 

The  original  VOACAP  (referring  to  the  version  obtained  by  SSC-Pac  from 
NTIA/ITS)  FORTRAN  program  used  strict  80  column  format  with  a  specific  output 
format.  The  file  and  folder  names  were  based  on  early  Microsoft  DOS  requirements. 
SSC-Pac  modified  the  code  so  that  it  could  compile  using  Intel  Visual  FORTRAN  10.2 
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and  created  dynamic  link  libraries  (dll)  for  use  in  Microsoft  Windows  operating  systems. 
To  support  data  communications  using  dll  files  SSC-Pac  removed  all  “SAVE”  and 
“WRITE”  statements  and  also  restrictions  on  path,  folder  and  file  names.  Several  other 
changes,  detailed  in  OAML-SDD-96  (2010b,d)  and  related  to  modernizing  the 
FORTRAN  code,  were  also  perfonned.  Some  bugs  including  common  block 
misalignments  and  noninitialized  variables  were  fixed. 

Instead  of  the  fixed  field  formats  for  environmental  data  input  and  prediction 
outputs,  the  current  SSC-Pac  implementation  of  VOACAP  uses  XML  fonnatted  data 
structures  (examples  in  Appendices  A  and  B).  The  antenna  specifications  use  two  files: 
(1)  a  control  file  with  a  table  of  needed  parameters  for  antenna  perfonnance  and  (2)  a  file 
with  specific  antenna  parameters.  The  program  first  reads  the  control  file  which  contains 
a  reference  to  the  specifc  antenna  parameters,  thus  allowing  specification  of  the  antenna 
angle  and  gain  pattern. 

Personnel  from  Lockheed  Martin,  Civil  Programs,  Space  and  Science  Solutions, 
perfonned  a  Quality  Assurance  Verification  (QAV)  for  the  SSC-Pac  implementation  of 
VOACAP  (Lockheed  Martin,  20 10a, b).  Lockheed  Martin  compiled  VOACAP  using 
Intel  Visual  Fortran  version  1.1  integrated  with  the  Microsoft  Visual  Studio  2008  using  a 
Dell  pentium  processor  operating  at  3.2  Ghz  with  3.5  GB  of  RAM.  The  operating  system 
was  Microsoft  Windows  XP  Professional  Version  2002,  Service  Pack  2.  Several  changes 
were  required  to  succesfully  execute  the  compilied  program.  This  included  moving 
various  files  to  different  locations  and  the  config.xml  file  had  to  be  modified  to  point  to 
the  correct  locations.  Neither  of  the  last  two  suggestions  were  implemented  in  the 
VOACAP  version  supplied  to  the  authors  of  this  CIMREP  report.  The  authors  also  had 
to  make  some  of  these  (and  other)  changes  to  make  the  program  run  properly,  as  detailed 
in  a  later  section. 

Various  attempts  by  Lockheed  Martin  to  compile  the  VOACAP  source  code  in  a 
Linux  environment  were  unsuccessful  due  to  the  use  of  Intel  record  structures  that  were 
not  supported  by  the  varioius  compilers  that  were  tried.  The  QAV  found  that  some  of  the 
output  values  were  slightly  different  than  expected.  These  differences  were  attributed  to 
round  off  errors  and  were  not  significant. 

The  Lockheed  Martin  QAV  report  recommends  VOACAP  as  a  Navy  standard 
within  a  Windows  (PC)  environment.  They  also  recommend  that  the  Intel  Fortran  record 
structures  be  converted  into  standard  FORTRAN  95/90  data  types  for  portability  between 
compilers.  Finally  they  recommend  that  a  “makefile”  be  provided  and  the  “software  be 
modified  and  tested  thoroughly  within  Unix/Linux  environments  before  it  is  submitted 
for  OAML  approval.” 

III.  Approach 

A.  Meetings 

As  noted  in  the  Introduction  section  of  this  report,  the  authors  did  not  convene  a 
special  meeting  with  HF  experts  to  evaluate  VOACAP.  It  was  felt  that  infonnation 
provided  by  SSC  -  Pacific  (OAML-SDD-96,  2010a,b,c,d)  ,  the  QAV  report  (Lockheed 
Martin,  2010b)  and  various  online  sources  were  sufficient  to  evaluate  the  suitability  of 
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VOACAP  for  Navy  uses.  P.  Guest  did  meet  with  the  official  developer  of  the  program  at 
SSC-Pacific  to  get  feedback  on  the  report  findings  ,  as  described  in  Section  VIII. 

B.  Criteria 

1 .  Installation 

The  authors  attempted  to  install  the  program  on  several  different  PCs  and 
documented  the  steps  required  to  make  the  program  execute  properly.  The  authors  did 
not  attempt  to  compile  the  supplied  source  code  but  instead  used  the  FORTRAN 
executable  code  that  was  supplied.  The  authors  evaluated  the  installation  procedure,  as 
described  in  the  findings  section  below. 

2.  User  Interface  and  Ease  of  Use 

The  authors  evaluated  and  documented  these  factors  as  described  below. 

3.  Accuracy  of  Prediction 

It  was  not  feasible  to  conduct  an  actual  field  test  to  verify  the  accuracy  of  the 
VOACAP.  However  based  on  its  long  history  and  continued  use  and  recommendation  by 
HF  experts,  it  is  our  opinion  that  this  is  one  of  the  most  accurate  and  reliable  HF 
prediction  programs  available  today.  The  authors  perfonned  a  series  of  tests  to  verify 
that  the  SSC-Pacific  implementation  performed  as  expected.  Because  the  VOACAP  CD 
did  not  include  any  graphics  output,  the  authors  wrote  computer  code  using  Matlab  to 
parse  the  XML  format  output  data  and  plot  areal  coverage  and  point-to-point  results  to 
allow  for  inspection  of  the  results  and  comparison  with  other  implementations  of 
VOACAP. 

The  tests  consisted  of  the  following: 

•  Running  the  supplied  version  of  VOACAP  using  inputs  from  the  sample  test  case 
provided  in  the  Software  Test  Description  (OAML-SDD-96,  2010a)  to  verify  that 
the  output  values  were  identical  to  those  given  in  this  document.  There  was  one 
areal  coverage  and  one  point-to-point  test  case.  The  XML  input  files  that  were 
used  in  the  two  sample  test  cases  are  contained  in  Appendix  A  and  the  ouput  files 
are  in  Appendix  B. 

•  Comparing  the  plots  of  output  data  from  these  sample  test  cases  with  similar  plots 
from  the  Advance  Refractive  Effects  Prediction  System  (AREPS)  tactical 
decision  aid. 

•  Comparing  the  plots  of  output  data  from  these  sample  test  cases  with  similar  plots 
from  the  online  version  of  VOACAP  at  the  Perkiomaki  web  site 
http://www.voacap.com. 
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•  Comparing  the  plots  of  output  data  from  these  sample  test  cases  with  similar  plots 
from  Problab  2.0,  which  is  a  commercially-available  stand-alone  HF  prediction 
program. 

•  Perfonning  a  series  of  test  cases  that  explored  the  input  parameter  space,  as 
specified  in  the  Software  Requirements  Specification  (OAML-SDD-96,  2010c). 
For  these  tests,  the  maximum  and  minimum  value  of  a  particular  parameter  were 
used  as  input  into  VOACAP.  These  included  environmental  parameters,  EM 
system  parameters  and  antenna  parameters.  In  addition,  the  program  was  tested 
using  different  geographical  locations,  times  of  day  and  times  of  year.  One  aspect 
of  the  test  was  to  see  if  the  program  crashed  or  produced  errors  by  using  extreme 
locations  in  the  input  parameter  space.  Another  aspect  was  to  detect  potential 
bugs  in  the  code  by  examining  the  output  in  a  qualitative  sense.  Table  1,  in 
section  IV. E.  below,  shows  the  various  test  cases  that  were  executed. 

The  results  of  these  test  are  described  in  a  later  section. 


C.  Sources  of  Data 

As  described  above,  in  addition  to  the  two  sample  test  cases,  the  authors  varied 
the  different  input  parameters,  based  on  the  provided  allowable  input  ranges  (see  Table 
1).  Plots  of  results  from  the  VOACAP  predictions  were  compared  with  similar  plots 
from  AREPS,  Proplab  2.0  and  the  online  VOACAP. 

IV.  Findings 

A.  Installation 

The  installation  procedure  was  time-consuming  and  not  straightforward,  requiring 
several  days  of  effort  and  phone  calls  to  SSC-Pacific  to  get  the  compiled  version  of 
VOACAP  to  properly  execute.  There  was  a  readme.txt  file  (shown  in  Appendix  C)  on 
the  provided  CD  but  it  was  buried  deep  in  the  file  structure  and  not  easy  to  find.  The 
readme.txt  file  did  not  contain  all  the  needed  infonnation  to  install  and  run  the  program 
and  the  information  provided  was  not  easy  to  understand,  at  least  for  the  authors  who  are 
environmental  scientists,  not  computer  system  experts.  There  was  also  infonnation  about 
running  the  program  in  various  locations  of  the  supplied  documents  (OAML-SDD-96, 
2010a,b,c,d).  None  of  this  information  was  complete,  nor  was  it  logically  organized. 

The  name  of  the  batch  file  that  calls  the  executable  FORTRAN  program 
“RFPS_fileio.bat”,  is  not  intuitive  to  people  not  familiar  with  RFPS  and  it  was  buried 
three  layers  deep  in  the  file  structure.  Some  of  the  directory  names  were  lengthy  and 
cumbersome;  these  were  modified  by  the  authors  for  ease  of  use. 

The  authors  had  to  perform  the  following  steps  to  get  the  program  to  run 
without  errors: 
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1.  Modify  the  RFPS\Config.XML  to  specify  where  the  files  are:  The  original  defaults 
were: 

<SystemDatabase>C:\Documents  and  Settings\etheridgej\Desktop 

\V  O  AC  AP_Q  AVANALY  S  IS\Q  AV\RFP  S_  1 5\RFPS_  1 5\Data\System\ArepsDatabas 

e.XML</SystemDatabase>\ 

<DtedFolder>C:\Documents  and  Settings\etheridgej\Desktop 
\V  O  AC  AP_Q  A  V_ANALYSIS\DTED</DtedFolder> 

<DataFolder>C:\Documents  and  Settings\etheridgej\Desktop 
\VOACAP_QA  V_ANALYSIS\Q  AV\RFPS_  1 5\RFPS_  1 5\Data</DataFolder> 

These  were  changed  to  (changes  indicated  by  red  text): 

<SystemDatabase>C:\VOACAP\VOACAP\RFPS_15\RFPS_15\Data\System\ArepsD 
at  aB  ase .  XML</S  y  stemD  atab  as  e> 

<DtedFolder>C:\  DTED</DtedFolder> 

<DataFolder>C:\VOACAP\VOACAP\RFPS_l  5\RFPS_1 5\Data</DataFolder> 

2.  Copy  the  coeffs\  folder  to  the  Ionosphere  folder: 

C:\  \V  O  AC  APW  O  AC  AP\RFPS_  1 5\  RFPS_15\Data\Ionosphere\coeffs 

3.  Copy  the  coeffs  folder  also  to  RFPS_15\  and  rename  it  Dcoeffs. 

4.  No  DTED  terrain  data  was  provided  with  the  CD.  The  authors  had  to  obtain  this 
from  other  sources  and  copy  into  the  DtedFolder  as  shown  in  the  config.XML. 

The  above  required  modifications  were  not  clearly  stated  anywhere  in  the 
readme.txt  file  nor  in  any  of  the  other  documentation  except  for  this  general  statement  in 
the  readme.txt  file: 

“3)  You  may  have  to  modify  C:\Program  Files\RFPS\Config.XML  to  specify  where  your 
DTED  folder  is  located.” 

B.  Execution 

After  debugging  and  making  these  changes,  the  authors  were  able  to  run  the 
program  and  produce  the  XML  output  files  using  a  PC  operating  in  a  Windows  XP 
environment.  After  several  attempts  using  a  variety  of  computers,  it  was  determined  that 
the  supplied  executable  file  could  not  run  on  PCs  with  Windows  Vista,  Windows  7  or 
Windows  8.  In  hindsight,  this  was  not  surprising,  because  the  FORTRAN  compiler  used 
to  create  the  executable  was  designed  for  Windows  XP.  However  this  information  was 
not  stated  anywhere  on  the  supplied  CD. 

The  authors  did  not  attempt  to  compile  or  execute  the  program  in  a  UNIX  or 
LINUX  computer,  see  earlier  comments  from  the  QAV  (Lockheed  Martin,  2010b) 
regarding  the  difficulties  of  using  VOACAP  in  these  types  of  operating  systems. 
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C.  Producing  Usable  Output  Data 

The  VOACAP  output  is  produced  in  fdes  using  XML  data  structures  (see  sample 
test  case  example  in  Appendix  B).  For  the  areal  coverage  and  point-to-point  sample  test 
cases  (one  each)  the  output  numbers  were  compared  directly  with  the  supplied  examples. 
However,  performing  a  manual  inspection  of  all  the  test  cases  (in  Table  1,  below)  was  not 
practical  because  of  (1)  the  large  amount  of  data,  even  for  just  one  run,  (2)  the 
comparison  programs  did  not  readily  produce  the  data  in  the  same  formats  for  easy 
comparison  and  (3)  to  evaluate  the  accuracy  and  realism  of  the  many  test  cases,  graphical 
displays  were  required.  No  plotting  programs  were  provided  with  the  CD.  Therefore,  the 
authors  wrote  several  computer  programs  using  Matlab  to  parse  the  output  data  and  plot 
the  results  in  similar  fonns  as  the  comparison  programs.  This  included  contour  plots 
showing  the  global  field  strength  coverage  and  time  series  plots  showing  the  24  hour 
variations  field  strength  from  the  point-to-point  output  data. 

Once  the  data  had  been  parsed,  it  was  relatively  straightforward  to  use  GIS 
mapping  tools  to  produce  global  coverage  diagrams  such  as  Figure  1  below  and  allow 
easy  comparisons  with  the  other  model  outputs. 

Producing  a  MUF/LUF  diagram  was  more  difficult.  Although  the  XML  input 
parameter  “Method”  in  the  input  file  includes  several  options  for  choosing  MUF  and 
LUF  outputs  for  a  particular  24  hour  period,  only  field  strength  is  output  for  all  Method 
choices.  There  was  no  documentation  on  how  to  produce  a  MUF/LUF  time  series  for  a 
24  hour  (or  any  other)  period.  Therefore,  to  allow  comparison  of  the  MUF/LUF 
predictions  with  the  comparison  programs,  the  point-to-point  program  was  run  using  the 
same  inputs  except  the  frequency  was  varied  from  2  to  30  MHz,  and  the  field  strength 
time  series  outputs  for  each  frequency  were  stored  in  uniquely  named  data  files.  A 
Matlab  program  was  created  that  would  take  the  output  for  each  frequency  to  create  an 
array  of  predicted  field  strengths  as  a  function  of  time  and  frequency.  A  contour  plot  of 
this  array  produced  a  color  coded  field  strength  plot  as  function  of  time  (X  axis)  and 
frequency  (Y-Axis),  see  Figure  3,  below.  This  is  not  the  same  thing  as  a  MUF/LUF 
diagram,  which  is  not  a  contour  plot  but  rather  a  time  series  of  lines  showing  the  specific 
MUF  and  LUF  frequency  values  for  a  particular  path  and  time  interval.  However,  the 
field  strength  contour  plot  is  very  similar  to  a  MUF/LUF  diagram  (both  show  time  and 
frequency  on  the  X  and  Y  axes)  and  usually  there  are  regions  with  sharp  drop-offs  in  field 
strength  in  time-frequency  space  that  can  be  used  to  make  “eyeball”  estimates  of  the 
MUF  and  LUF  time  series.  The  online  version  of  VOACAP  produced  circuit  reliability 
(%)  contour  plots  in  time-frequency  space;  this  parameter  is  derived  from  field  strength 
and  thus  allows  qualitative  visual  comparisons.  To  produce  true  MUF/LUF  diagrams,  a 
threshold  field  strength  would  need  to  be  detennined  and  from  this  the  MUF  and  LUF  for 
each  time  step  identified  and  plotted  as  a  line  time  series.  Although  this  would  be  an 
important  step  in  an  operational  implementation  of  VOACAP,  it  was  not  required  for  this 
CIMREP  and  therefore  not  attempted. 

Several  other  output  data  parameters  besides  field  strength  are  required  for  any 
user  application  product  based  on  VOACAP,  such  as  NITES-NEXT,  according  to 
OAML-SDD-96  (2010c).  (See  section  II.B.2  above)  including  Signal-to-noise  Ratio 
(SNR),  Reliability,  Required  Power  Gain,  Signal  Power,  MUF,  LUF  and  Propagation 
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Angle  and  several  others,  but  these  parameters,  are  not  in  the  output  files.  As  noted, 
MUF  and  LUF  outputs  are  listed  available  output  parameters  in  the  online  versions  of 
VOACAP,  but  these  or  any  of  the  other  output  options  were  not  available  in  the  version 
submitted  for  inclusion  in  OAML. 

D.  Sample  Test  Case  Results 
1 .  Areal  Coverage 

The  provided  CD  had  XML  text  files  that  contained  the  numerical  ouput  for  the 
areal  coverage  sample  test  case  (see  Appendix  A  for  the  exact  input  parameters 
specifications  used  and  Appendix  B  for  the  numerical  output  files).  A  comparison  of  the 
supplied  test  case  output  with  the  output  produced  by  authors  showed  identical  values  in 
both  cases.  This  demonstrates  that  the  areal  coverage  part  of  the  program  was  correctly 
implemented. 

Figure  2  shows  global  coverage  diagrams  of  the  output  produced  by  the  authors 
with  similar  contour  plots  produced  by  AREPS  and  the  online  version  of  VOACAP, 
respectively.  For  AREPS  and  the  online  VOACAP,  not  all  the  same  input  parameters  as 
the  CD  VOACAP  were  available;  but  the  authors  tried  to  match  the  inputs  as  best  as 
possible.  Also  the  authors  were  unable  to  plot  the  same  output  parameter  in  each  of  the 
three  model  versions.  For  the  VOACAP  being  evaluated  here,  field  strength  is  plotted; 
for  the  AREPS  version,  signal-to-noise  ratio  at  required  reliability  (in  this  case  90%)  is 
plotted;  for  the  online  version  of  VOACAP,  circuit  reliability  is  plotted.  For  these 
reasons,  the  contour  plots  shown  in  Figure  2  do  not  look  identical.  However  they  are 
very  similar  and  the  authors  interpret  this  to  mean  that  the  CD  version  of  VOACAP  is 
accurately  producing  the  same  results  (or  nearly  the  same)  results  as  the  AREPS  and 
online  versions.  The  authors  also  note  that  the  coverage  diagram  makes  sense  from  a 
physical  point  of  view:  for  the  relatively  low  frequency  used  (10  MHz)  one  expects  that 
the  field  strength  to  more  or  less  fall  off  with  distance  and  with  no  obvious  skip  and 
bounce  patterns.  Other  cases  using  higher  frequencies  (not  shown  here)  produced 
patterns  that  showed  the  expected  skip  features  and  also  reasonable  behavior  with  respect 
to  daytime  and  nighttime  coverage,  such  as  more  daytime  absorption  and  polar  region 
effects.  The  authors  conclude  that  the  version  of  VOACAP  submitted  for  inclusion  in  the 
OAML  appears  to  be  correctly  implemented  and  produces  accurate  predictions. 

2.  Point-to-Point  Time  Series 

The  authors  perfonned  a  similar  comparison  (as  the  areal  coverage  test  above)  for 
the  point-to-point  output  fields  using  the  sample  test  data  file  output  on  the  supplied  CD. 
As  with  the  areal  coverage,  the  point-to-point  output  fields  were  identical,  indicating  that 
VOACAP  was  correctly  implemented. 

As  described  in  Section  IV. C,  the  authors  developed  code  that  allowed  the 
VOACAP  output  to  be  compared  with  field  strength  (or  proxies)  time  series  as  a  function 
of  time  and  frequency.  For  this  comparison  the  authors  used  the  same  sample  test  case 
inputs,  with  the  exception  of  frequency  which  was  varied  by  1  Mhz  increments  from  2 
Mhz  to  30  Mhz,  as  required  to  produce  the  appropriate  graphics  for  comparison  with  the 
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VOACAP  Standard  Case 


Field  Strength 


■  -215- -150  ■  -74- -50  -34-  -30  19  15  |  -4  -  0  ■  10  - 13  ■  23  -  28 

■  -149- -100  |  -49- -40  -29 --25  -14  -  -10  ■  1  -  5  ■  14  - 17  ■  29  -  51 

■  -99- -75  -39- -35  -24-  -20  -9-  -5  ■6-9  ■  18 -22 


TX  (32.00N,  117. 00W),  Oct,  17  UTC,  10.100  MHz,  1.20  kW,  SSN  77,  Mode:  CW 
TX  Ant:  [voaant/vl4.ant  ],  RX  Ants:  [voaant/vl4.ant  ] 

1100% 

90% 

80% 

|7°% 

4  60% 

4  50% 

4  40% 

y  3°% 

■  20% 

110% 

0% 

Figure  2.  Contour  plots  showing  areal  coverage  for  the  sample  test  case  for 
VOACAP  (top  panel),  AREPS  (middle  panel),  and  the  online  version  of 
VOACAP  (bottom  panel).  The  three  panels  show  field  strenth  (dBu),  Signal  to 
noise  ratio  at  90%  reliability  (dB)  and  circuit  reliability  (%)  respectively. 
Although  different,  these  parameters  are  all  measures  of  signal  power  and  show 
similar  patterns  between  the  different  models. 
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AREPS  and  online  VOACAP  versions  (Figure  3).  As  before,  it  was  not  possible  to 
produce  exactly  the  same  contour  colors  as  the  online  VOACAP  nor  be  certain  that  all 
the  inputs  were  identical.  Also,  as  before,  different  output  parameters  were  plotted  for 
the  different  model  versions.  However,  the  three  figures  show  a  very  similar  pattern,  and 
the  expected  diurnal  changes  are  present.  This  is  more  evidence  that  VOACAP  is 
correctly  implemented  and  producing  apparently  accurate  results. 

E.  Input  Parameter  Space  Test  Results 

According  to  the  OAML-SDD-96  (2010b)  documentation,  a  variety  of  output 
parameters  are  available  from  VOACAP,  although  this  is  not  the  case  in  the  submitted 
version.  For  example  by  choosing  the  “Method”  parameter  equal  to  20  in  the  input  file,  a 
“complete  system  performance”  is  supposed  to  be  available,  this  includes  a  variety  of 
output  variables  including  Signal-to-noise  Ratio  (SNR)  at  all  modes,  Reliability  (% 
chance  of  successful  cornrns),  Required  Power  Gain,  Signal  Power,  Probability  of 
Occurrence,  MUF  and  LUF.  However,  the  only  output  parameter  generated  was  Field 
Strength  at  Receiver  in  dBu  units.  This  was  the  same  output  parameter  provided  in  the 
sample  test  case  described  above.  The  authors  tried  using  different  values  of  the 
“Methods”  including  one  that  the  documentation  stated  would  produce  a  MUF/LUF 
table.  However,  only  Field  Strength  was  produced  in  the  ouput  files.  Therefore,  the 
authors  were  only  able  to  evaluate  the  VOACAP  signal  strength  output  parameter. 

Changing  the  Method  input  parameter  produced  errors  and  failure  to  execute  in 
some  cases.  For  example  setting  Method  =  20  in  the  sample  test  case  point-to-point  input 
file  produced  an  error  statement.  In  the  sample  test  case  areal  coverage  input  file,  the 
Method  was  set  to  20  and  the  program  executed  properly.  Apparently  different  Method 
values  require  different  input  parameters  to  be  specified.  These  issues  were  not  discussed 
in  any  of  the  available  documentation. 

The  authors  executed  point-to-point  predictions  using  the  stated  minimum  and 
maximum  value  for  a  variety  of  parameters  (summarized  in  Table  1).  For  all  of  these 
cases  the  program  appeared  to  execute  properly  and  field  strength  values  were  produced 
in  the  output  file.  In  many  cases,  changing  the  input  parameters  had  no  effect  on  the 
outputted  field  strength;  these  cases  are  indicated  by  the  word  “same”  in  the  Table  1 
“Notes”  column.  This  was  expected  in  most  cases  for  parameters  such  as 
“ReqSignalToNoiseRatio”  that  do  not  affect  field  strength.  However,  the  “Geomagnetic 
Index”  would  be  expected  to  affect  field  strength  and  yet  no  differences  in  output  were 
noted  when  this  input  parameter  was  changed.  Unfortunately  because  the  authors  were 
only  able  to  produce  field  strength  output,  they  were  not  able  to  test  the  effects  of  input 
variables  related  to  receiver  characteristics  or  man-made  noise,  for  example.  Parameters 
such  as  Transmitter  Frequency,  Receiver  Latitude/Longitude  and  Sunspot  number  did 
produce  differences  in  the  field  strength  output,  as  expected. 
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Field  Strength  for  frequencies  from  2  to  30  MHz 
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Figure  3.  Contour  plots  showing  24  hour  time  variations  at  various  frequencies  for  the 
point-to-point  test  sample  case  for  VOACAP  (top  panel,  field  strength  dBu),  AREPS 
(middle  panel,  signal-to-noise  ratio,  dB),  and  the  online  version  of  VOACAP  (bottom 
panel,  circuit  reliability  %).  The  contour  colors  are  the  same  as  the  respecitive  panels  in 
Figure  2,  i.e.  stronger  signals  in  red,  weaker  in  blue.  As  in  Figure  2,  these  parameters 
are  all  measures  of  signal  power  and  show  similar  patterns  between  the  different 
models.  These  plots  are  similar  to  MUF/LUF  diagrams;  the  MUF  would  be  somwhere 
at  the  top  of  the  red  areas  while  the  LUF  would  be  at  the  bottom  of  the  red  areas,  or  the 
default  value  of  2  Mhz  if  no  blue  area  exists  below. 
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Table  1  Parameter  Space  Test  Summary 


Case 

Parameter 

Value 

Output  filename 

Notes 

1 

Default 

VOA  P2P  stdcase.xml 

2 

Path 

Long 

case2_output.xml 

Same  result  as  std 

case 

3a 

ReqCircuitReliability 

1 

case3a  output.xml 

Same 

3b 

66 

50 

C  ase3  boutput .  xml 

Same 

4a 

Req  S  ignalT  oNoiseRatio 

-30 

Case4a  output.xml 

Same 

4b 

66 

99 

C  ase4b_output .  xml 

Same 

5a 

MultipathPowerTolerance 

0 

Case5a  output.xml 

Same 

5b 

66 

40 

C  ase5  boutput .  xml 

Same 

6a 

MultipathT  imeDelay 

0 

Case6a_output.xml 

Same 

6b 

66 

99.99 

C  ase6b_output .  xml 

Same 

7a 

Transmitter  frequency 

2 

Case7a  output.xml 

Also  changed 
DesignFreq  to 
match. 

Different 

7b 

66 

30 

C  ase7b_output .  xml 

66 

Different 

8a 

Type 

02 

Case8a_output.xml 

Change  receiver 
type  also 

Same  as  standard 

case 

8b 

Type 

47 

Case8b_output.xml 

Change  receiver 
type  also 

Same  as  standard 

case 

9a 

Latitude 

-90 

Case9a  output.xml 

Same 

9b 

66 

0 

Case9b_output.xml 

Same 

10a 

Orientation 

90 

Case  1  Oaoutput.xml 

Same  as  standard 

case 

10b 

66 

180 

Case  1  Oboutput.xml 

Same  as  standard 

case 

11a 

MinTakeoffAngle 

40 

Casella  output.xml 

Same 

12a 

Power 

0.001 

Case  12a  output.xml 

Same 

12b 

66 

1000 

Case  12b  output.xml 

Same 

12c 

66 

9999 

Casel2c_output.xml 

Same 

13a 

Receiver  Ant  Gain 

-90 

C  ase  1 3  aoutput.  xml 

Same  as  standard 

case 

13b 

66 

90 

Case  1 3b_output.xml 

Same  as  standard 

case 

14a 

Receiver  Latitude  / 
longitude 

-32 

-117 

Case  14a  output.xml 

Same 

14b 

Receiver  Lat  /  Long 

32 

Case  14b  output.xml 

Same 

15 


117 

15 

Sunspot  number 

250 

Case  1 5_output.xml 

Same 

16 

IonModel 

URSI88 

Case  1 6_output.xml 

Same  as  standard 

case 

17a 

MultiplierELayer 

0.1 

Case  17a  output.xml 

Similar  to  standard 
case  for  some 
hours,  but  different 
for  others 

17b 

Multiplier  ELayer 

3 

Case  1 7b_output.xml 

Same 

18a 

Geomagnetic  Index 

0 

Case  18a  output.xml 

Same  as  standard 

case 

18b 

Geomagnetic  Index 

8 

Case  1 8b_output.xml 

Same  as  standard 

case 

V.  Changes  Required  and  Specific  Recommendations 

This  section  describes  the  changes  that  the  authors  believe  should  be  implemented 
before  VOCAP  is  officially  included  in  the  OAML  library.  It  is  possible  that  some  of 
these  suggestions  are  not  required  for  inclusion  in  OAML.  Therefore  this  section  should 
be  considered  to  represent  a  basis  for  discussion  among  the  developers  and  stakeholders 
and  not  necessarily  as  absolute  requirements. 

A.  Model  Physics 

The  authors  were  satisfied  that  the  physical  and  statistical  integrity  of  the 
VOACAP  model,  including  the  CD  version  produced  by  SSC-Pacific,  is  sound,  for  the 
various  reasons  discussed  earlier.  The  model  uses  a  statistical  approach  and  it  is  not 
likley  that  the  model  prediction  would  ever  produce  perfect  predictions  for  a  particular 
situation.  However,  we  believe  that  an  inaccurate  prediction  would  more  likely  be  due  to 
errors  in  the  input  parameters  or  misconceptions  by  the  users  rather  than  errors  in  the 
representation  of  physical  processes  in  the  model.  No  changes  in  the  actual  core  model 
code  are  required  at  this  time  for  inclusion  in  OAML.  However,  as  documented  in  the 
online  VOACAP  web  sites,  Greg  Hand  and  perhaps  other  HF  experts  may  make  changes 
to  the  code  as  bugs  or  other  problems  are  discovered.  We  recommend  that  if  a  Navy 
Version  of  VOACAP  is  included  in  the  OAML,  someone  should  be  responsible  for 
keeping  abreast  of  monitoring  changes  that  are  being  done  to  other  versions  of  VOACAP 
and  decide  whether  these  are  relevent  and  significant  enough  to  merit  modifying  the 
Navy  implementation. 

VOACAP  predictions  do  not  directly  incorporate  day-to-day  space  weather 
effects,  but  instead  are  based  on  monthly  averages  of  mostly  benign  space  weather 
situations.  There  appears  to  be  a  capability  to  include  space  weather  effects  by  use  of  the 
“layer  multiplier”  input  variables.  The  program  would  be  considerably  more  useful  if 
there  was  some  way  that  space  weather  effects  could  be  either  automatically  or  at  least 
more  easily  incorporated  into  the  program,  either  by  use  of  the  layer  multipliers  or  some 
other  method.  Or  some  guidance  could  be  provided  in  documentation. 

B.  Implementing  VOACAP 
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The  authors  suggest  that  a  set-up  utility  be  created  that  could  automate  the 
implementation  procedure  as  much  as  possible.  This  could  include  creating  a  logical 
default  directory  structure  and  naming  conventions. 

C.  Output  Parameters 

Field  strength  at  receiver  is  the  only  output  parameter  that  is  produced  and  output 
in  the  current  version  as  implemented.  According  to  the  Software  Requirements 
Specification  (OAML-SDD-96,  2010c),  21  output  variables  are  required.  Parameters 
such  as  MUF  and  LUF  are  essential  for  almost  every  application  of  an  HF  prediction 
program,  but  they  are  not  directly  available  in  the  output.  Although  only  having  Field 
Strength  at  Reciever  may  be  sufficient  to  meet  OAML  needs  (potential  developers  can 
use  Field  Strength  to  derive  other  parameters),  the  authors  recommend  that  other  output 
variables  be  made  available  in  an  OAML  version.  The  rationale  is  that  as  long  as  the 
input  variables  (such  as  man-made  noise,  Tx  and  Rx  features,  etc.)  are  in  place  in  the 
available  versions  of  VOACAP  to  produce  output  variables  other  than  Field  Strength, 
these  should  be  available  in  an  OAML  version  to  avoid  the  the  extra  development  cost  of 
calculating  these  values  outside  of  the  core  version  available  from  OAML.  In  the 
authors’  opinion,  VOACAP  should  have  the  ability  to  provide  the  user  with  MUF/LUF 
outputs  and  other  important  output  parameters,  but  whether  this  is  actually  required  needs 
to  be  decided  by  others. 

Although  it  is  expected  that  tactical  decision  aid  developers  would  produce  their 
own  methods  for  visually  displaying  the  output  field  in  areal  coverage  diagrams  and  time 
series  plots  for  MUF/LUF,  reliability  etc.,  it  would  be  helpful  to  have  some  type  of 
plotting  capability  provided  as  a  development  aide.  The  authors  created  Matlab  programs 
for  this  purpose  and  can  make  these  available. 

The  Software  Requirements  Specification  (OAML-SDD-96,  2010c)  states  on 
page  17  “NTIA  recommends  that  VOACAP  not  be  used  for  a  LUF  calculation”  due  to  a 
problem  with  negative  values  being  produced  when  the  required  reliability  is  not  met. 
This  is  a  strange  statement  that  needs  to  be  examined  in  more  detail.  Apparently  this 
issue  has  been  overcome  or  ignored  in  the  AREPS  implementation. 

D.  Documentation 

Several  changes  and  additions  to  the  documentation  should  be  created,  described  in 
the  following  bullets. 

•  There  should  be  a  readme.txt  file  placed  in  the  top  directory  layer  of  the  CD  with 
clear  instructions  on  how  to  implement  and  execute  VOACAP  or  at  least  clear 
references  to  where  this  information  can  be  found.  This  would  not  be  difficult  to 
do  and  would  save  considerable  effort  and  wasted  time  by  potential  developers 
who  need  to  use  this  product. 

•  There  needs  to  be  documentation  that  better  describes  the  Method  parameters  and 
what  other  input  parameters  need  to  be  provided  in  the  XML  fields  for  each  of  the 
possible  Method  values. 
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There  needs  to  be  documentation,  perhaps  with  screen  shots  that  shows  the  step 
by  step  procedures  required  to  be  able  to  make  VOACAP  properly  execute. 


•  The  needs  to  be  documentation  that  clearly  states  where  more  information  on 
VOACAP  can  be  obtained,  e.g.  suggested  web  links  such  as 
http://www.voacap.com/. 

•  There  need  to  be  links  to  HF  training  material  in  the  documentation  (see  next 
section) 

E.  Training  Requirements 

Successfully  use  of  VOACAP  requires  some  knowledge  of  HF  propagation,  HF  radio 
systems  and  antennas.  While  an  inexperienced  person  could  probably  run  the  program, 
the  results  would  most  likely  be  in  error.  As  a  result  of  untrained  use,  the  program  would 
get  a  reputation  of  not  being  an  accurate  prediction  tool,  and  its  use  among  Navy 
personnel  would  drop. 

Many  aspects  of  the  training  need  to  be  provided  to  users  of  VOACAP;  this  report 
will  not  discuss  all  the  details.  One  notable  example  would  be  understanding  how  to 
incorporate  space  weather  effects  into  the  VOACAP  inputs;  how  to  do  this  was  not 
apparent  to  the  authors. 

Although  training  is  not  the  responsibility  of  OAMF,  it  should  be  made  clear  that  this 
is  necessary  for  both  tactical  decision  aid  developers  who  would  implement  VOACAP 
and  also  the  end  users  of  such  products.  Because  HF  is  not  extensively  used  by  the  Navy, 
the  motivation  for  providing  such  training  may  be  lacking.  The  training  issue  needs  to  be 
addressed  if  the  Navy  is  serious  about  using  VOACAP  for  operational  use. 

There  should  be  links  to  educational  material  on  HF  propagation  in  the  VOACAP 
documentation.  At  the  very  least,  the  users  should  be  made  aware  of  the  most  common 
problems  that  are  likely  to  result  in  inaccurate  predictions.  An  excellent  example  of  this 
is  the  “Ten  Common  Mistakes  in  Using  VOACAP”  by  Perkiomaki  at 
http://www.voacap.com/10mistakes.html.  Users  also  need  to  be  aware  that  VOACAP 
only  predicts  skywave  propagation  and  therefore  may  underpredict  signal  strengths  at 
medium  ranges  (<  1500  km)  where  surface  wave  propagation  can  be  significant, 
particularily  for  lower  frequencies  in  the  HF  range. 

F.  Operating  Systems 

The  executable  version  of  VOACAP  only  runs  on  the  Windows  XP  operating  system, 
which  is  essentially  obsolete.  Although  individual  developers  may  be  able  to  compile  the 
source  code  for  different  operating  systems,  this  may  be  a  difficult  task.  The  authors 
recommend  that  the  compilation  procedure  be  tested  on  more  recent  systems  (including 
64-bit)  such  as  Windows  7  and/or  Windows  8. 

A  decision  must  be  made  on  whether  VOACAP  should  have  the  ability  to  operate  on 
a  FINUX  or  UNIX  system.  Based  on  the  descriptions  in  the  QAV  (Fockheed  Martin, 
2010b),  this  requires  considerable  changes  to  the  code;  their  intitial  attempts  were 
unsuccessful.  However,  due  to  some  recent  work  by  Jim  Watson,  affilation  unknown,  it 
appears  that  a  version  of  VOACAP  that  runs  under  UNIX  or  FINUX  is  now  available  at 
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no  cost.  Details  can  be  found  at  http://www.qsl.net/hz  1  iw/voacapl/index.html.  If  it  is 
determined  that  this  capability  is  needed  for  Navy  use,  the  authors  recommend  that  the 
new  code  developed  by  Watson  be  tested  and  included  in  OAML. 

VI.  Developer  Response  to  Findings  and  Recommendations 

P.  Guest  met  with  the  official  “developer”  of  the  submitted  VOACAP  program  at 
SSC-Pacffic,  APB  in  San  Diego  CA,  Ms.  Amalia  Barrios,  on  November  7,  2012.  The 
word  “developer”  is  in  quotes  because  Ms.  Barrios  was  not  actually  the  primary 
developer  of  this  version  of  VOACAP  or  its  implementation  in  AREPS;  that  person 
retired  from  SSC-Pac  after  the  VOACAP  version  evaluated  in  the  report  was  put  on  the 
provided  CD.  Ms.  Barrios  maintains  the  VOACAP  implementation  in  AREPS  and  has 
considerable  familiarity  with  the  program,  but  she  acknowledges  that  she  is  not  an  HF 
modeling  expert  and  is  not  familiar  with  all  the  details  of  the  VOACAP  core  model  and 
the  related  files  on  the  CD  version  evaluated  by  the  authors. 

Ms.  Barrios  and  Dr.  Guest  discussed  in  some  detail  most  of  the  issues  referenced 
in  this  report.  Ms.  Barrios  agreed  with  all  the  findings  and  recommendations  presented 
by  the  authors  of  this  report.  She  stated  that  due  to  lack  of  resources  and  available  HF 
expertise,  SSC-Pac  was  not  able  at  the  current  time  to  address  the  issues  identified.  If 
resources,  including  the  hiring  or  contracting  of  an  HF  modeling  expert,  were  available  to 
SSC-Pac,  Ms.  Barrios  stated  that  SSC-Pac  would  be  able  to  address  the  issues  identified 
in  this  report  and  create  a  version  of  VOACAP  suitable  for  inclusion  in  the  OAMF. 

Ms.  Barrios  was  recently  provided  with  a  final  draft  copy  of  this  report  and 
commented  via  email.  She  confirmed  that  she  agreed  with  the  results  and 
recommendations,  except  that  she  noted  that  it  was  the  intent  of  SSC-Pac  to  only  include 
signal  strength  as  an  output  parameter.  The  OAMF  submitted  version  is  a  model,  not  an 
application  of  VOACAP,  similar  to  APM,  the  model,  being  incorporated  into  the  AREPS 
application.  An  application  can  then  use  the  results  of  the  model  to  derive  the  other 
parameters  such  as  Signal  to  Noise  Ratio,  Reliability,  MUF/LUF  etc.  She  also 
emphasized  the  point  that  no  one  at  SSC-Pac  or  elsewhere  in  the  Navy  “really  officially 
maintains  it”. 

VII.  Conclusions  and  Final  Recommendations 

The  authors  do  not  recommend  that  the  current  version  of  VOACAP  be  included 
in  OAMF.  The  core  physics  and  statistics  in  VOACAP  are  sound,  and  the  program  is 
considered  to  be  the  “gold  standard”  by  many  HF  experts.  This  product  could  potentially 
be  very  useful  to  the  US  Navy.  However,  the  version  provided  to  the  authors  of  this 
report  as  a  candidate  for  inclusion  into  OAML  is  unacceptable  in  many  ways.  Installing 
the  program  on  a  PC  was  not  intuitive,  and  required  debugging  before  it  would  run.  The 
supplied  FORTRAN  compiled  executable  file  only  worked  on  Window  XP  operating 
systems.  The  FORTRAN  source  code  could  potentially  be  compiled  on  other  systems, 
but  this  needs  to  be  tested.  Implemention  on  UNIX/LINUX  systems  would  require 
substantial  changes  or  the  use  of  newer  versions  of  VOACAP  developed  outside  the 
Navy. 
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The  submitted  program  produces  outputs  of  Field  Strength  at  Receiver  only.  This 
may  be  sufficient  for  its  inclusion  in  OAML.  However,  it  is  essential  for  any  useful 
application  of  an  OAML  VOACAP  that  the  21  other  recommended  output  variables  be 
available  to  the  final  user,  ft  may  be  cost  effective  to  include  options  for  these  useful  and 
essential  parameters  in  an  OAML  version  of  VOACAP,  relieving  later  developers  of  this 
task. 

The  documentation  required  to  install  and  execute  the  program  is  hard  to  find, 
scattered  and  incomplete.  This  needs  to  be  improved.  Other  tools,  such  as  plotting 
programs  to  display  the  results  would  also  be  helpful,  although  perhaps  not  required  for 
inclusion  in  OAML. 

Although  not  necessarily  essential  for  inclusion  in  OAML,  if  VOACAP  is  to  be 
used  by  developers  and  operators  of  HF  systems,  they  should  be  trained  on  basic  HF 
principles  as  well  as  the  specific  use  of  the  Navy  Version  of  VOACAP.  This  is  not  a 
product  that  could  be  successfully  employed  by  a  casual  user  without  such  training. 

If  the  Navy  is  going  to  make  the  commitment  to  include  VOACAP  in  OAML, 
resources  will  need  to  be  provided  for  further  development  of  the  product  to  address  the 
issues  discussed  in  this  report.  Another  important  resource  requirement  is  to  have  a  “go¬ 
to”  person  who  is  highly  knowledgeable  about  the  OAML  version  of  VOACAP  and  be 
available  for  consultation  when  the  inevitable  difficulties  arise  from  developers  and  end 
users  in  the  future.  The  Navy  needs  to  determine  whether  it  is  worth  the  expense  needed 
to  include  VOACAP  in  the  OAML,  when  anyone  within  DoD  can  very  easily  get  a 
working  version  of  VOACAP  online.  Development  efforts  could  focus  on  providing  the 
specific  system,  antenna,  target  and  environmental  input  parameters  and  procedures 
required  for  accurate  predictions  of  operational  HF  communication  systems  using  already 
available  applications  rather  than  developing  a  complete  HF  prediction  package. 

VIII.  Disclaimer 

The  views  expressed  in  this  report  represent  the  best  good  faith  efforts  of  the 
authors  to  evaluate  the  appropriateness  of  VOACAP  for  inclusion  in  OAML.  However, 
the  opinions  expressed  here  should  not  be  considered  to  represent  official  US  Navy 
policy  or  opinions.  Any  reference  to  a  commercial  product  does  not  imply  an 
endorsement  of  that  product  by  the  US  Navy  or  any  part  of  the  US  Government. 
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X.  Appendix  A  -  Test  Sample  Input  Files 

A.  Areal  Coverage  Sample  Test  case  Input  File 

<?xml  version-' 1.0"  encoding="UTF-8"  ?> 

<RFPS> 

<VOACAP  ID="any"  ShowInput="On"> 

<Method>20</Method> 

<DateTime>2009- 1 0-07T 1 7:04 :47Z</DateT  ime> 

<Path>Short</Path> 

<ReqCircuitReliability  Unit="%">90</ReqCircuitReliability> 
<ReqSignalToNoiseRatio  Unit="dB">20</ReqSignalToNoiseRatio> 
<MultipathPowerTolerance  Unit="dB">3</MultipathPowerTolerance> 
<MultipathTimeDelay  Unit="usee">0.  l</MultipathTimeDelay> 
<Transmitter> 

<Frequency  Unit="MHz">  1 0</Frequency> 

<T  ype>0</T  ype> 

<Latitude  Unit="deg">32</Latitude> 

<Longitude  Unit="deg">-1 17</Longitude> 

<Orientation  Unit="deg">0</Orientation> 

<MinTakeoffAngle  Unit="deg">0</MinTakeoffAngle> 

<Power  Unit="kW">5</Power> 

<DesignFreq  Unit="MHz">10</DesignFreq> 

</Transmitter> 

<Circuit> 

<Latitude  Unit="deg">32</Latitude> 

<Longitude  Unit="deg">-1 17</Longitude> 

<CenterName>Location  name</CenterName> 

<WesternBoundary  Unit="deg">-180</WestemBoundary> 
<EasternBoundary  Unit="deg">  1 80</EasternBoundary> 
<NorthemBoundary  Unit="deg">84.30667</NorthernBoundary> 
<SouthernBoundary  Unit="deg">-90</SouthemBoundary> 
<GridType>l</GridType> 

<GridSize>30</GridSize> 

</Circuit> 

<Receiver> 

<Type>0</Type> 

<AntGain  Unit="dBi">0</AntGain> 

<Orientation  Unit="deg">0</Orientation> 

</Receiver> 

<Environment> 

<SunspotNum>75</SunspotNum> 

<IonModel>CCIR</IonModel> 

<MultiplierELayer>  1  </MultiplierELayer> 

<MultiplierF  1  Layer>  1  </MultiplierF  1  Layer> 

<MultiplierF2Layer>  1  </MultiplierF2Layer> 
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<MultiplierSporELayer>  1  </MultiplierSporELayer> 

<ManMadeNoise  Unit="-dBw/Hz">l  5()</ManMadcNoisc> 
</Environment> 

</VOACAP> 

</RFPS> 

B.  Point-to-point  Sample  Test  Case  Input  File 

<?xml  version-' 1.0"  encoding="UTF-8"  ?> 

<RFPS> 

<VOACAP  ID="any"  ShowInput="On"> 

<Method>26</Method> 

<DateT  ime>2009- 1 0-07T 1 7:04:47Z</DateTime> 

<Path>Short</Path> 

<ReqCircuitReliability  Unit="%">90</ReqCircuitReliability> 
<ReqSignalToNoiseRatio  Unit="dB">20</RcqSignalToNoiseRatio> 
<MultipathPowerTolerance  Unit="dB">3</MultipathPowerTolerance> 
<MultipathTimeDelay  Unit="usee">0.  l</MultipathTimeDelay> 
<Transmitter> 

<Frequency  Unit="MHz"> 1 0.00</Frcquency> 

<Type>0</Type> 

<Latitude  Unit="deg">32</Latitude> 

<Longitude  Unit="deg">-1 17</Longitude> 

<Orientation  Unit="deg">0</Orientation> 

<MinTakeoffAngle  Unit="deg">0</MinTakeoffAngle> 

<Power  Unit="kW">5</Powcr> 

<DesignFreq  Unit="MHz">10.000</DesignFreq> 

</Transmitter> 

<Receiver> 

<Type>0</Type> 

<  AntGain  Unit=  "  dB  i "  >0</AntGain> 

<Latitude  Unit="deg">20</Latitude> 

<Longitude  Unit="deg">-120</Longitude> 

</Receiver> 

<Environment> 

<SunspotNum>75</SunspotNum> 

<IonModel>CCIR</IonModel> 

<MultiplierELayer>  1  </MultiplierELayer> 

<MultiplierF  1  Layer>  1  </MultiplierF  1  Layer> 

<MultiplierF2Layer>  1  </MultiplierF2Layer> 
<MultiplierSporELayer>  1  </MultiplierSporELayer> 

<ManMadeNoise  Unit="-dBw/Hz">150.4</ManMadeNoise> 
<GeomagneticIndex>4</GeomagneticIndex> 

</Environment> 

</VOACAP> 

</RFPS> 
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XI.  Appendix  B  -  Test  Sample  Output  Files 

A.  Areal  Coverage  Sample  Test  Case  Output  Files  (first  few  lines) 
<AreaData> 

<GridPoint> 

<Latitude  Units="Deg">-90</Latitude> 

<Longitude  Units="Deg">0</Longitude> 

<FieldStrength  Units="dBu">-86.4</FieldStrength> 

</GridPoint> 

<GridPoint> 

<Latitude  Units="Deg">-83.9897</Latitude> 

<Longitude  Units="Deg">- 1 80</Longitude> 

<FieldStrength  Units="dBu">-73.  l</FicldStrength> 

</GridPoint> 

<GridPoint> 

<Latitude  Units="Deg">-83.9897</Latitude> 

<Longitude  Units- 'Deg">- 167. 5862</Longitude> 

<FieldStrength  Units="dBu">-74.3</FicldStrength> 

</GridPoint> 

<GridPoint> 

<Latitude  Units="Deg">-83 .9897</Latitude> 

<Longitude  Units="Deg">-155. 1724</Longitude> 

<FieldStrength  Units="dBu">-75.6</FieldStrength> 

</GridPoint> 

(This  is  a  long  file  that  includes  global  data,  just  the  first  few  lines  are  showm  above) 

B.  Point-to-point  sample  test  case  input  file  (entire  file) 

<PointData> 

<Point> 

<Hour>0</Hour> 

<FieldStrength  Units="dBu">48</FieldStrength> 

</Point> 

<Point> 

<Hour>  1  </Hour> 

<FieldStrength  Units="dBu">50</FieldStrength> 

</Point> 

<Point> 

<Hour>2</Hour> 

<FieldStrength  Units="dBu">53</FieldStrength> 

</Point> 

<Point> 

<Hour>3  </Hour> 

<FieldStrength  Units="dBu">55</FieldStrength> 

</Point> 

<Point> 
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<Hour>4</Hour> 

<FieldStrength  Units="dBu">54</FieldStrength> 
</Point> 

<Point> 

<Hour>5  </Hour> 

<FieldStrength  Units="dBu">55</FieldStrength> 
</Point> 

<Point> 

<Hour>6</Hour> 

<FieldStrength  Units="dBu">5  l</FieldStrength> 
</Point> 

<Point> 

<Hour>7  </Hour> 

<FieldStrength  Units="dBu">50</FieldStrength> 
</Point> 

<Point> 

<Hour>8</Hour> 

<FieldStrength  Units="dBu">49</FieldStrength> 
</Point> 

<Point> 

<Hour>9</Hour> 

<FieldStrength  Units="dBu">47</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 0</Hour> 

<FieldStrength  Units="dBu">44</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 1  </Hour> 

<FieldStrength  Units=MBu">41</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 2</Hour> 

<FieldStrength  Units="dBu">41</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 3</Hour> 

<FieldStrength  Units-'dBu">48</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 4</Hour> 

<FieldStrength  Units="dBu">49</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 5  </Hour> 

<FieldStrength  Units="dBu">48</FieldStrength> 
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</Point> 

<Point> 

<Hour>  1 6</Hour> 

<FieldStrength  Units="dBu">47</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 7  </Hour> 

<FieldStrength  Units="dBu">42</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 8</Hour> 

<FieldStrength  Units="dBu">34</FieldStrength> 
</Point> 

<Point> 

<Hour>  1 9</Hour> 

<FieldStrength  Units="dBu">30</FieldStrength> 
</Point> 

<Point> 

<Hour>20</Hour> 

<FieldStrength  Units="dBu">29</FieldStrength> 
</Point> 

<Point> 

<Hour>2 1  </Hour> 

<FieldStrength  Units="dBu">3  l</FieldStrength> 
</Point> 

<Point> 

<Hour>22</Hour> 

<FieldStrength  Units="dBu">37</FieldStrength> 
</Point> 

<Point> 

<Hour>23  </Hour> 

<FieldStrength  Units="dBu">45</FieldStrength> 
</Point> 

<Point> 

<Hour>24</Hour> 

<FieldStrength  Units="dBu">48</FieldStrength> 
</Point> 

</PointData> 

</V OAC AP  Results> 


</RFP  S_Output> 


XII.  Appendix  C  -  VOACAP  CD  Readme  File 


To  use  RFPS : 

1)  You  must  have  the  Microsoft  .NET  Framework  2.0  on  your  computer. 
(Its  free) 

2)  Unzip  RFPS.zip  to  C:\Program  Files\RFPS 
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You  should  now  have  a  file:  'C:\Program  Files\RFPS\Rfps.exe' 

3)  You  may  have  to  modify  C:\Program  Files\RFPS\Conf ig . XML  to  specify 
where 

your  DTED  folder  is  located. 

4)  Double  click  Rfps_FileIO.bat  and  then  look  in  Data\Output  for  the 
results . 


Contents : 


.  \RFPS\  RFPS  Executable  and  all  support  DLLs 

Also  Config.XML  which  must  be  modified  (see  below) 


RFPS . exe 


65,536  10/13/09  Main  program 


Apm37NetLib . dll 
ApmLib37 . dll 

ApmLib37 . dll 
APM  version  2.3.09 
ArepsDB . dll 
database 

GeLDted.dll 
database  files . 

GeLGCD.dll 
circle  distances . 
GeLPacks . dll 
LfMf3Lib.dll 
version  3 . 0 

LFMFLib.dll 

LfMf3Lib.dll 

VoacapLib . dll 
VoacapLib30 . dll 

VoacapLib30 . dll 
model .  version  3 . 0 


77,824  10/13/09  Routines  used  to  interface  with 

974,848  09/02/08  Fortran  DLL  version  3.7  using 

69,632  10/13/09  Routines  used  to  manipulate  the 

40,960  10/13/09  Routines  used  to  read  the  DTED 

49,152  10/13/09  Routines  used  to  calculate  Great 

397,312  10/13/09  General  purpose  routines. 

913,408  09/29/09  Fortran  coded  DLL  of  LFMF  model. 

32,768  10/13/09  Routines  used  to  interface  with 

49,152  10/13/09  Routines  used  to  interface  with 

1,519,616  10/13/09  Fortran  coded  DLL  of  Voacap 


Config.XML  Configuration  file.  (You  may  need  to  modify  this 

file . ) 

Rfps_FileIO.bat  Example  of  a  Windows  batch  file  used  to  test  File 

I/O 


RFPS.exe  /infile  "Data\Input\APM_absorb . xml"  /outfile 

"Data\Output\APM_absorb . xml " 

RFPS.exe  /infile  "Data\Input\VOA_area . xml"  /outfile 

"Data\Output\VOA_area . xml " 

Rfps_stdin.bat  Example  of  a  Windows  batch  file  used  to  test 

Standard  I/O 

RFPS  /stdin  <Data\Input\APM_absorb . xml 

>Data\Output\APM_absorb . xml 


Data 


Folder  containing  data  files 


Data\System\ArepsDataBase . XML 
Data\ Ionosphere 

Folder  containing  all  neccessary  files  for  VOACAP  runs . 
Do  not  modify  this  folder  or  its  contents . 
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Data\ Input 

Sample  XML  input  files 
Data\Output 

Sample  output  files  generated  by  RFPS  using  files  in 

Data\ Input 


Sample  Config.XML  file  used  in  RFPS: 

<?xml  version=" 1 . 0 " ?> 

<Conf iguration> 

<SystemDatabase>C : \ Program 

Files\RFPS\Data\System\ArepsDatabase . XML</ SystemDatabase> 
<DtedFolder>C : \DTED</DtedFolder> 

<DataFolder>C : \Program  Files\RFPS\Data</DataFolder> 
</Configuration> 


notes:  The  contents  of  ' <DtedFolder> '  must  contain  subfolders  such  as 
W117  which  in  turn 

contain  files  such  as  N32.DT1. 

Example  with  the  above  configuration:  'C:\DTED\W117\N32.DT1' 

The  contents  of  ' <DataFolder> '  must  contain  the  subfolder 
' Ionosphere ' 

Example  with  the  above  configuration:  'C:\Program 

files\RFPS\Data\Ionoshpere ' 

<SystemDatabase>  does  NOT  have  to  be  the  related  to 
<DataFolder>  although 

its  a  good  way  to  organize  it. 

<DtedFolder>  can  reside  on  a  seperate  server.  i.e. 

' \\Server\DTED ' 


RFPS  Usage : 

Command  line  arguments:  (not  case  sensitive) 

/stdin  Reads  data  from  standard  input. 

/stdout  Outputs  data  to  standard  output. 

/infile  pathname  Reads  from  file  if  not  Stdin  (Ignored  if  /stdin 

is  used) 

/outf  ile  pathname  Writes  data  to  outf  ile .  (Can  be  used  in 

conjunction  with  /stdout) 


Sample : 

RFPS.EXE  /stdin  <Data\absorb . xml  >Data\absorb_Out . xml 

RFPS.EXE  /infile  "Data\absorb . xml"  /outf ile  "Data\absorb  out2.xml" 


Points  of  contact: 

Wayne  Patterson  619-553-1423  wayne.patterson@navy.mil  (Areps , 
Enviro) 
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Amalia  Barrios 
Gary  Lindem 


619-553-1429  amalia . barrios @navy . mil 
619-553-1421  gary . lindem@navy.mil 


(APM) 

(RFPS) 


29 


INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 


3.  Research  Sponsored  Programs  Office,  Code  41 
Naval  Postgraduate  School 
Monterey,  CA  93943 


4. 


Mr.  Walt  Moskal 

Naval  Meteorology  and  Oceanography  Command 
1100  Balch  Ave 

Stennis  Space  Center,  MS  39529-5000 


30 


